Skip to content

Put breakpoints on the line number margin and let a file type restrict them - #357

Merged
hendrikmennen merged 1 commit into
one-ware:mainfrom
FEntwumS:feature/breakpoint-line-pattern
Sep 10, 2026
Merged

hendrikmennen merged 1 commit into
one-ware:mainfrom
FEntwumS:feature/breakpoint-line-pattern

Conversation

@danielpourbakhsh

@danielpourbakhsh danielpourbakhsh commented Aug 28, 2026 •

Copy link
Copy Markdown
Contributor

Changes around the editor margin, all of them needed before a debug session can do anything with a breakpoint: where it is drawn, who owns it, and which lines may carry one.

  • Breakpoints move onto the line numbers. A line that carries one shows the dot in place of its number, as Rider and VS Code do. MeasureOverride stays inherited, so the column is exactly as wide as it was before.
  • BreakPointMargin stays, marked [Obsolete].
  • One store instead of one per editor. ExtendedTextEditor handed every margin a new BreakpointStore(), so a breakpoint lived in an object no debug session ever saw. The margin gets BreakpointStore.Instance now, and a breakpoint survives closing and reopening its file.
  • A file type can restrict which lines take a breakpoint. ITypeAssistance.BreakPointLinePattern is a regular expression, null meaning no restriction — a language without a rule notices nothing of this. Our Assembly Dialect needs it:
    because otherwise a breakpoint on a data word, a comment or an annotation slips.
  • SetEnableBreakpoints takes the ITypeAssistance instead of a single bool, because the margin needs the flag and the pattern.
  • A breakpoint says whether the target armed/verified it. BreakPoint records it and the margin draws a grey hollow ring when it did not. The store raises VerificationChanged for that, since the change does not alter the collection, a margin listening only to CollectionChanged would never repaint. The store also says whether the target is running — while it is, the margin takes no breakpoint.

@danielpourbakhsh
danielpourbakhsh force-pushed the feature/breakpoint-line-pattern branch from 21280bc to 8aa3e64 Compare September 4, 2026 20:49
@danielpourbakhsh danielpourbakhsh changed the title Let a file type declare which lines can carry a breakpoint and BreakPointStore is now a Singleton per File Put breakpoints on the line number margin and let a file type restrict them Sep 4, 2026
@danielpourbakhsh
danielpourbakhsh force-pushed the feature/breakpoint-line-pattern branch from 8aa3e64 to eb55a47 Compare September 4, 2026 20:52
…t them

Three changes that belong together, all around the editor margin.

Breakpoints move onto the line numbers: a line that carries one shows the dot
in place of its number, as Rider and VS Code do. MeasureOverride stays
inherited, so the column is exactly as wide as it was without breakpoints.

BreakPointMargin stays and is marked obsolete. Nothing in the tree points at it
any more, but it is public API, so it goes out with the next batch rather than
on its own. It loses a leak on the way: the store outlives the margin, so the
subscription moves into OnTextViewChanged and is released when the margin
detaches.

ExtendedTextEditor handed every margin a new BreakpointStore(), so a
breakpoint lived in an object per editor that no debug session ever saw. The
margin gets BreakpointStore.Instance instead, which also lets a breakpoint
survive closing and reopening its file.

ITypeAssistance gains BreakPointLinePattern, a regular expression whose null
means no restriction, so a language without a rule notices nothing. Not every
line of every language can carry a breakpoint: in assembly one on a data word
does not fail but slips, because the line table has no entry for it and the
backend moves it to the next line that has code. The rule travels as data and
not as a predicate - a callback would put the core into plugin code on every
click and every pointer move over the margin. Removing a breakpoint always
stays possible, and the preview dot appears only where a click would take
effect.

SetEnableBreakpoints therefore takes the ITypeAssistance instead of a bool:
the margin needs the flag and the pattern as a unit.

BreakPoint carries whether the target armed it, and the margin draws a grey
hollow ring when it did not, inside the same diameter so the column keeps its
width. The store raises VerificationChanged for that, because the change
alters no collection and a margin listening only to CollectionChanged would
never repaint. The store also carries whether the target is running; while it
is, the margin takes no breakpoint in either direction and says why. Both stay
inert until a debug session sets them.
@danielpourbakhsh
danielpourbakhsh force-pushed the feature/breakpoint-line-pattern branch from 6ff1575 to fea546e Compare September 8, 2026 17:47
@danielpourbakhsh
danielpourbakhsh marked this pull request as ready for review September 8, 2026 18:11
@hendrikmennen
hendrikmennen merged commit 008715f into one-ware:main Sep 10, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants